(Much of this section written by Jesper Skov)
Since the release kernels found at the various Linux/m68k sites are compiled for the average user, they contain drivers for just about every piece of hardware supported by Linux. They will also be compiled so they can be run on all the processors in the Motorola 68000 family.
This scheme enables everybody to boot Linux, but it also reduces the performance of Linux: drivers for hardware you don't have or use take up (non-swappable) memory, and in case of processor specific programming, it is required to check which set of instructions to run.
Therefore, if you are a bit adventurous and have time to spare, you should recompile a kernel for your machine configuration. Especially if you are not a kernel hacker (i.e., you don't care about all those 2-3 line patches :) and use the same kernel for several days/weeks, the time will be well-spent. (Of course, if you are a kernel hacker, the time will be well-spent as well. :)
Recompiling your own kernel will make it possible to configure it to your exact machine configuration, thus giving the best performance possible.
The Linux/m68k sources are available by FTP from sunsite.auc.dk in "/local/os/linux/680x0/vx.x", x.x denoting the latest version numbers.
The sources are also mirrored at the sites listed in FTP Sites.
DO NOT try to use standard Linux kernel source trees (from
e.g. ftp.kernel.org) to compile Linux/m68k. These trees are
often out-of-date and may include serious bugs due to changes being
made on some architectures not being propagated to Linux/m68k. Stick
to Jes's source trees (or Jesper's for Linux/APUS) unless you really
know what you are doing.
You will need at least gcc version 2.7.2 (preferably 2.7.2.1 or later) to compile the kernel.
Recompiling the kernel for the MC68060 processor requires binutils 2.7.0.3 or later, fixing a linking problem with the ifpsp (integer/floating point support) files.
Linux 2.1.x and later require binutils 2.7.0.3 (or later) with the CHIP fix. This makes it possible to specify which processor (chip) the instructions should be assembled for. Thus it is now possible to write mnemonics instead of opcodes for the bigger processors, easing the reading of the code and removing the problem of wrong mnemonic/opcode translations.
GCC can be found at any of the Linux/m68k FTP sites (see Linux/m68k ftp sites). The required version of the binutils package can be found at ftp://sunsite.auc.dk/local/os/linux/680x0/bin/.
There are three important stages: configuring the kernel; generating
the dependencies and compilation of the main kernel (vmlinux);
and building modules. You can choose to either use modules
(non-essential modules can be demand-loaded by the kernel) or not use
modules (which means all of your drivers will be built into the
kernel). Using modules makes your kernel and drivers slightly bigger,
but if you don't use several devices most of the time (like your
printer port, CD-ROM, and various filesystem formats) you will save
system memory when they are not in use (as none of the kernel itself
can be swapped to disk).
Note that this is a generic set of instructions; Debian comes with a package called "kernel-package" that automates the compilation and installation steps (and integrates them into the Debian package system; a side benefit of installing kernel-package is that installing it makes you install all of the other packages needed to compile a kernel). No doubt Red Hat has a similar facility. In any event, the general principles discussed here apply no matter how you actually compile the kernel.
cd to your kernel source directory
(e.g. cd /usr/src/linux)
make config. (If you have the ncurses headers
installed on your system, you may want to use make menuconfig
instead, because it is more forgiving of mistakes, though it is
slower. You can also use make xconfig if you have Tcl/Tk and
want to configure under X, or make oldconfig if you have already
configured a kernel and just want to be prompted for new options.)
M to many of the questions to build a module.
kerneld or kmod support (and be sure to get a copy
of modutils and install it on your system).
This part is easy. Type make clean; make dep; make (all on one
line, with semicolons between each command). Then go away while your
computer heats your house; the compilation speed depends on (a) how
much RAM you have, (b) how fast your CPU is and (c) how fast your hard
drive and its controller are. Slow computers (like 68020s) can take
over a day to compile a kernel; some 68060 owners have reported
compilation times measured in minutes. Some computers (with lots of
RAM) will benefit from running the last make as a parallel make
(using the -j switch); see the manual page for make for
details. When it is done, you should have a file called vmlinux
with the kernel in it.
Compiling the modules is also easy; type make modules; make
modules_install and then go home and eat popcorn (you can combine
this line with the compilation line above, e.g. chain the 5 makes
together on one line). You should end up with a lot of files under
/lib/modules/X.Y.Z (where X.Y.Z is your kernel version
number).
Generally, all you should need to do is copy the vmlinux file to
wherever your bootstrap expects to find it (for ataboot and amiboot,
this will be on a native filesystem partition; for LILO it will
probably be in / or /boot, but this can be
configured differently). Make sure you keep a copy of your previous
vmlinux file where you can get to it (or set up LILO so you can
boot from the previous file if necessary), just in case something goes
wrong.
Linux/m68k releases are built and released by Jes Degn Sørensen. "Built" means that you can write a patch against the current version or patchlevel and send it to Jes and he will integrate it into one of the next releases. Make sure you state against which version the patch was made. Please note that Jes has no way to test Atari-specific patches.
It is also considered good etiquette to send your patch to the Linux/m68k mailing list, so (a) Jes can see if other people say it works (a crude form of peer review, if you will) and (b) so everyone else on the list has a new patch to fool around with (a crude form of everyone getting their kernel-hacking fix ;).
Note: If you patch processor-specific code (e.g. 68030 vs. 68040 MMU or FPU) make sure that you document the dependencies.
Send bug reports to the author of the code or to Jes. Probably a better approach is to post it to the linux-m68k mailing list or to the appropriate newsgroup. If there are bugs that will probably stay in the code for an extended period of time let me know so I may publish them here.
Problem:
Linux reports *** COPROCESSOR PROTOCOL VIOLATION *** FORMAT=9 or
something similar.
Fix:
Pull the 16L8 PAL's pin 11 free (this is the signal 'XBG') and solder it to +5V. This prevents the PAL from tri-stating AS and DS until XBGACK has gone low.
To make your 32 MHz daughter-card work:
****This applies to the CA400771 32 MHz daughter board****
**********Other boards should not have this bug***********
_______________________________________________________________
Atari 32 Meg Daughter Board / PGA |
|
___________________ |
| | |
| | |
2 1 1 1 1 1 1 1 1 1 |
0 9 8 7 6 5 4 3 2 1 |
. . . . . . . . . . . . . . . . . . . . |
PAL 16R4-7PC PAL 16L8-7PC |
. . . . . . . . . . . . . . . . . . . . |
1 2 3 4 5 6 7 8 9 1 |
0 |
CA400771 |
___________________________________________________________|
|
|
___|
Problem:
When using a GVP card with 16 bit RAM on an Amiga with 68040, Linux/m68k dies. (This also happens with Commodore A2052 boards.)
Fix:
Unfortunately, there is no known solution to that problem. So your best bet is to get some real 32 bit RAM. The 16-bit RAM may still be used as a ramdisk using the z2ram device, see the z2ram device.
When using the 2.0.x (and earlier) kernels, you must stop it from being used as normal RAM (-m option of amiboot). Quoting from the README for amiboot:
If you have some non-AutoConfig memory you want to use under Linux, or if you
want to disable some parts of your memory (e.g. Zorro II RAM on '040 based
systems), you have to use a memory file and the --memfile option. This file
contains information about the memory chunks you want to use under Linux. The
format for the file is:
chipramsize
[0xfastchunkaddr fastchunksize]
[0xfastchunkaddr fastchunksize]
...
For example, if you don't want Linux to use your 2nd meg of chipram, you would
create a file that looks contains only:
1048576
If you had 1M of chip ram, 2M of 16 bit FAST ram at address 0x200000 and 16M of
32 bit FAST ram at address 0x80000000, and you didn't want Linux to use the
slow 16 bit FAST ram, you'd create a file that looks like:
1048576
0x80000000 16777216
The memory file can also be used to specify in which block of memory the kernel
will be put. Normally Amiboot will put the kernel in the first block of Fast
RAM it will find. If you use a memory file, it will put the kernel in the first
block of fast RAM you specify.
In recent 2.1.x kernels and the 2.2 pre-releases, the 16-bit ram is automatically disabled on Zorro-III systems, so you don't need to make a memory file.
Problem:
You get strange system crashes and segmentation faults with a Zorro II SCSI controller and an Amiga 3000 or 4000 with a Commodore A3640 (revisions 3.0 and 3.1).
Fix:
The immediate fix is to make your SCSI controller stop using DMA. If
you're using a A2091 or GVP Series II controller, add the kernel
parameter wd33c93=nodma:1 to the boot command you are using.
However, this will result in irritatingly slow disk accesses.
A better solution is to replace the A3640 with a newer version of the card (revision 3.2) or a third-party card like the Phase5 Cyberstorm, Warp Engine, GVP/QuikPak 4060D, or Apollo 4060. You may also be able to upgrade your A3640 yourself, if you have some electronics knowledge.
(written by Jesper Skov)
Problem:
In order to streamline the design of the MC68060, Motorola left out the implementation of a few addressing modes and instructions. The '060 remains user-level compatible with the other family members by emulating these addressing modes and instructions in software.
Whenever the '060 encounters an unimplemented instruction, a special exception is taken that enters the ifpsp (Integer and Floating Point Software Package), which is part of the kernel. Here the instruction is emulated and processing is resumed.
Obviously, this adds an overhead to the use of the system and since gcc 2.7.2 uses the unimplemented instructions for 64 bit multiplication and division there is reason for concern. Judging from my tests (highly inaccurate :) I expect a boost of at least 10% when applications can be recompiled with an 060 aware gcc (that would be release 2.8.0, due out last year ;)
Fix:
Recompile applications with an 060-aware gcc when available. A patch to gcc 2.7.2 was recently posted that may also help.